The CAP theorem is a fundamental concept in distributed system architecture that describes an unavoidable trade-off between three core requirements: Consistency, Availability, and Partition Tolerance. In simple terms, it states that a distributed system cannot guarantee all three at the same time. This principle, introduced by computer scientist Eric Brewer, matters because it guides how we design reliable systems. If you’ve ever wondered why a banking app would rather go offline than show incorrect data, or why a social media feed might show slightly stale posts during outages, the CAP theorem provides the answer. It’s a must-know concept for system design interviews and real-world technical decision-making.

Overview of the CAP theorem

The CAP theorem states that it is impossible for a distributed system to simultaneously provide all three properties: consistency, availability, and partition tolerance. In other words, a distributed system can only guarantee two out of these three properties at any given time. The theorem highlights the inherent trade-offs that system designers must consider when building distributed systems.

• Consistency (C): In the context of CAP, consistency means that all nodes see the same data at the same time. More formally, every read receives the result of the most recent write – no matter which replica node it connects to. This is often referred to as strong consistency or linearizability. (Note: This is different from the “consistency” in ACID databases, which refers to validity of transactions. Here, we mean consistency across distributed replicas.) If you write some data, a consistent system ensures any subsequent read (on any node) will return that data.

• Availability (A): Availability means the system always responds to requests. Every request to a non-failing node must result in some response (either the latest data or possibly stale data, but it cannot ignore you or error out). In practice, this means even if parts of the system go down, the service as a whole is still accessible. An available system can tolerate node failures – clients can always read or write something.

• Partition Tolerance (P): Partition tolerance means the system continues to operate despite network partitions or communication failures between nodes. A partition is a break in connectivity that splits the network into disjoint parts. In a partition-tolerant system, even if nodes are cut off from each other due to network issues, each part can keep working (possibly in a degraded mode). Essentially, the system can lose arbitrarily many messages between nodes (or even whole nodes) and still keep going. In modern distributed systems, network partitions will happen (due to outages, delays, etc.), so tolerance to partitions is a must.